In the field of communications, service provider networks are undergoing consolidation due to market pressure to reduce telecommunication service provisioning overheads associated with maintaining multiple networks. In particular, there is a need to address cost/complexity issues related to provisioning Frame Relay (FR) services. Also, there is a need to address high bandwidth overheads incurred during content transport over Asynchronous Transfer Mode (ATM) infrastructure.
Internet Protocol (IP)/MultiProtocol Label Switching (MPLS)-based network provisioning enjoys an extensive deployment largely due to the availability of economic, high speed equipment suited for service-provider-side infrastructure deployment. IP/MPLS networks can support a variety of Layer-2 (L2) technologies; including Ethernet, ATM and FR.
Large organizations (customers) have multitudes of geographically displaced sites, which typically utilize Ethernet Local Area Network (LAN) infrastructure at each site. Traditionally, to provide L2VPN connectivity between these geographically displaced sites, FR services were used for inter-site connectivity between site-specific Customer Edge (CE) nodes because, FR technologies provide traffic differentiation and deterministic content transport. With the advent of IP/MPLS technologies, service providers can provide similar or better levels of Quality-of-Service (QoS) to the customer.
Service providers seek solutions for connecting their IP/MPLS networks with the customers' Ethernet infrastructure to provide low cost, efficient service offerings to customers, at a throughput comparable to traditional FR Virtual Leased Line (VLL) services and ATM services. However, unlike ATM and FR, plain vanilla Ethernet/IP content transport is performed in accordance with a broadcast/best-effort discipline in accordance with which packets propagate between source and destination nodes non-deterministically, and without guarantees, without necessitating infrastructure redundancy in conveying packets around failed infrastructure.
L2VPN services such as Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) can be provisioned over IP/MPLS networks.
VPWS coined by the Internet Engineering Task Force (IETF), generically refers to a L2VPN service that provides an Open Systems Interconnect (OSI) Layer-2 (link layer) point-to-point service (link emulation) connecting two CE nodes, associated with two corresponding customer sites, across a service provider's communications network. VPWS is also known as an Ethernet Virtual Private Line (EVPL) service if the source and destination network nodes are Ethernet based.
To provide content transport in an IP/MPLS network 10, unidirectional Label Switched Paths (LSPs) 12 are created between multiple Label Switching Routers (LSRs) 14 as shown in FIG. 1. In order to provide deterministic content transport and quality-of-service support, source routed LSPs 12 must be established in accordance with a traffic engineering MPLS protocol such as Resource Reservation Protocol-Traffic Engineering (RSVP-TE).
The introduction of MPLS technology not only provides support for deterministic traffic content transport but also provides a migration path for service providers in support of convergence leveraging currently deployed infrastructure. A multitude of transport layer/link layer/physical layer protocols and infrastructure are compatible with MPLS in conveying content. As such, MPLS may be provisioned over IP links 16 themselves provisioned over: an IP/Ethernet infrastructure (GigE), a Packet Over Synchronous Optical NETwork (SONET) (POS) infrastructure, an Asynchronous Transfer Mode (ATM) infrastructure, etc. No physical layer details of the infrastructure of the communications network 10 are shown in FIG. 1 nor relevant as an abstraction thereof is made in employing MPLS technologies.
In accordance with customer content traffic differentiation techniques, CEs 22 associated with customer sites 20 connect to corresponding PEs 24 via respective Attachment Circuits (ACs) 26. Each AC 26 may be either a physical or a logical circuit provisioned in accordance with the installed communications network edge infrastructure in the aggregation/distribution portion of the communications network 10. PEs 24 multiplex customer traffic (30) onto corresponding L2VPN connection(s) 40 (a pseudo wire L2VPN connection is show).
A Pseudo Wire (PW) 40 refers to an emulated bi-directional point-to-point connection over a packet-switched communications network 10 providing connectivity between two remote network nodes 22 employing any OSI layer-2 technology allowing content traffic arriving an interface 28 of a PE switch 24 to be directed across the core of communications network 10 to a corresponding interface 28 on the corresponding peer PE 24. PW technology gets its importance from what it brings to customers by extending customer services across long distances. PW mechanisms provide emulation of the essential attributes of a selected service through a core communications network 10 of a different infrastructure (and transport technology). From a customer's point of view, a PW 40 acts as an unshared link or circuit of a particular service—each content frame conveyed by one CE 22 over the PW 40 is received by, and only by, the remote peer CE 22. Content frame forwarding via a PW 40 is not affected by the content frames themselves, rather defined by the end-to-end PW virtual circuit 40 to which the content frame is submitted for transmission.
In order to support PW 40 connectivity in an MPLS domain, a targeted LDP session must be established between corresponding PEs 24 enabling the exchange of MPLS labels. Each targeted LDP session includes an LDP signaling link configured with knowledge of remote-peer loopback address information at each end. Only a single targeted LDP session is allowed between any pair of PEs 24. Further information regarding PW and VPLS support is provided in draft-ietf-pwe3-requirements-08.txt, published by the Internet Engineering Task Force (IETF), specification which is incorporated herein by reference.
Therefore, to support any arbitrary PW 40 in a service provider's communications network 10, a full mesh of bi-directional LSP tunnels 12 and targeted LDP sessions need to be established between participating PE nodes 24. The targeted LDP sessions enable setting up PWs 40 over the full mesh of LSP tunnels 12 which carry the PW content traffic.
Currently, PW-using-LSP connectivity is provisioned manually. The problem is that tens, or even hundreds, of PE nodes 24 are typically employed in a particular service provider network 10 to provide customer services and therefore the number of fully meshed bi-directional LSP tunnels and targeted LDP sessions between N PE 24 nodes is in the order of N(N−1). Therefore manual setup provisioning is lengthy and error-prone. Also, once the full mesh is provisioned, manually adding or removing a PE node 24 is also time consuming and error-prone.
A prior art United States. Application publication number. 2003/0177221 A1 entitled “Resource Allocation Using an Auto-Discovery Mechanism for Provider-Provisioned Layer-2 and Layer-3 Virtual Private Networks” which was published on Sep. 18, 2003, describes a method in accordance with which, rather than manually configuring VPN tunnels at each PE router, the VPN Capability Discovery Information (VCDI) is “piggy-backed” onto auto-discovery information as an extension to a conventional information distribution protocol, such as Border Gateway Protocol (BGP), Domain Name Service (DNS), and RADIUS. In order to implement the proposed method, auto-discovery protocols have to be extended to include the transmission of the VCDI information. After receiving such information, a tunnel is established by, and between, the appropriate PE nodes based on the information. While the solution has merit, it requires that each PE implement the modified auto-discovery protocol. The requirement suffers from complex implications related to the fact that multi-vendor heterogeneous PE equipment is typically employed in a typical communication network infrastructure and therefore the proposed solution need be adopted by multiple vendors. While the multiple vendors may adopt such a solution eventually, there is no telling how fast the solution may be deployed as all PE equipment will need upgrading. Further, vendors may see no incentive in upgrading older PE equipment rendering it obsolete and thus preventing service providers from leveraging their existing infrastructure investment.
Therefore there is a need to solve the above mentioned issues in provisioning VPN services over a managed communications network.